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Status of This Memo 
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Official Protocol Standards" (STD 1) for the standardization state 
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Abstract 


This document describes a new DHCPv6 option for passing a list of 
Simple Network Time Protocol (SNIP) server addresses to a client. 


1. Introduction 


This document describes a new option, called the SNTP [3] servers 
option, for passing information about SNTP servers in DHCPv6 [1]. 


2. Requirements 


The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
document, are to be interpreted as described in RFC 2119 [2]. 


3. Terminology 


This document uses terminology specific to IPv6 and DHCPv6 as defined 
in the "Terminology" section of the DHCPv6 specification [1]. 


4. Simple Network Time Protocol (SNIP) Servers Option 


The Simple Network Time Protocol servers option provides a list of 
one or more IPv6 addresses of SNTP [3] servers available to the 
client for synchronization. The clients use these SNIP servers to 
synchronize their system time to that of the standard time servers. 
Clients MUST treat the list of SNTP servers as an ordered list. The 
server MAY list the SNTP servers in decreasing order of preference. 
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The option defined in this document can only be used to configure 
information about SNTP servers that can be reached using IPv6. The 
DHCP option to configure information about IPv4 SNTP servers can be 
found in RFC 2132 [4]. Mechanisms for configuring IPv4/IPv6 dual- 
stack applications are being considered, but are not specified in 
this document. 


The format of the Simple Network Time Protocol servers option is as 
shown below: 


0 1 2 3 
Ord. 22. 3 ASO P28 Oo OT 2 Be 45, Oe ME 8 OsOe 1. 32. 3) cA O 7 289 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_SNTP_SERVERS | option-len | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


SNTP server (IPv6 address) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| SNTP server (IPv6 address) 


| | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


option-code: OPTION_SNTP_SERVERS (31) 


option-len: Length of the ’SNTP server’ fields, in octets; 
it must be a multiple of 16 


SNTP server: IPv6 address of SNTP server 
Appearance of This Option 


The SNTP servers option MUST NOT appear in messages other than the 
following: Solicit, Advertise, Request, Renew, Rebind, Information- 
Request, and Reply. If this option appears in messages other than 
those specified above, the receiver SHOULD ignore it. 


The option number for this option MAY appear in the Option Request 
Option [1] in the following messages: Solicit, Request, Renew, 
Rebind, Information-Request, and Reconfigure. If this option number 
appears in the Option Request Option in messages other than those 
specified above, the receiver SHOULD ignore it. 
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6. 


Security Considerations 


The SNIP servers option may be used by an intruder DHCPv6é server to 
cause DHCPv6 clients to contact a rogue SNIP server, resulting in 
invalid synchronization of time in the client, finally leading to 
time-critical applications running inaccurately in the client 


machine. Time accuracy can be crucial to some security algorithms. 
For example, expired certificates may gain a new life, making the 
applications running on the client machine less secure. The 


inaccuracy can even cause clients to set their time incorrectly, 
making them vulnerable to replay attacks in protocols that use time 
stamps to detect replays. 


To avoid attacks through these options, the DHCPv6 client SHOULD use 
authenticated DHCPv6 (see the "Authentication of DHCP messages" 
section in the DHCPv6 specification [1]). 


IANA Considerations 
The IANA has assigned an option code to the following from the 


option-code space defined in the "DHCPv6 Options" section of the 
DHCPv6 specification [1]. 


Option Name Value Described in 
OPTION_SNTP_SERVERS 31 Section 4. 
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